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FOREWORD 


During the past two years, Essex Corporation developed the 
Emergency Management Computer-Aided Trainer (EMCAT) system. This work 
was performed under contract NAS8-35815 to the Technology Utilization 
Office of the National Aeronautics and Space Administration (NASA), 
Marshall Space Flight Center (MSFC) . Technical direction was provided 
by the National Fire Academy (NFA) , an agency of the Federal Emergency 
Management Administration (FEMA) . The direction and support of Mr. 
Kenneth Smith and Ishmail Akbay of NASA/MSFC and Mr. William Blair NFA 
are gratefully appreciated. 

The purpose of the EMCAT system is to provide a low cost, 
realistic, real-time simulation system for training fire ground command 
personnel in resource allocation and strategy decisions. Multiple 
scenarios were developed to demonstrate the flexibility of the EMCAT 
system and its ability to fulfill various training needs. 

The EMCAT development effort was divided into two phases, the 
Requirements and Design Phase and the Implementation Phase. This cost 
sharing development effort resulted in three EMCAT systems, two for 
delivery to NASA and one for Essex Corporation's use. Five scenarios 
were also developed to operate on the system. 

Any comments or questions should be addressed to Kenneth Smith at 
(205) 453-1474 or Ricardo Rodriguez at (205) 837-2046. 
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1.0 INTRODUCTION 


This final report describes the Emergency Management Computer-Aided 
Trainer (EMCAT) developed by Essex Corporation under contract to NASA's 
Marshall Space Flight Center (MSFC) and the Federal Emergency Management 
Administration’s (FEMA) National Fire Academy (NFA) . This document 
constitutes a deliverable end item for the Implementation Phase of the 
EMCAT development contract. 

1 . 1 Background 

In early 1980, the Technology Utilization Office at MSFC was 
approached by the Huntsville Fire Department for help in developing a 
computer-based training system for fire fighting personnel. A prototype 
EMCAT system was developed by NASA first using video tape images and 
then video disk images when the technology became available. This 
prototype was demonstrated at various fire fighting conferences and was 
evaluated by personnel from the National Fire Academy. 

The association of these two federal agencies led to a development 
contract for an operational EMCAT system. This contract was awarded to 
Essex Corporation in October 1983. During the performance period of the 
contract, two operational EMCAT systems were to be produced for delivery 
to the Government. Also, various scenarios would be produced to develop 
a simulation methodology and to demonstrate the system's flexibility. 

The contract effort has led to a marketable fire ground incident 
training system, which the Essex Corporation intends to produce. 

The EMCAT system is meant to fill the training needs of the fire 
fighting community with affordable state-of-the-art technologies. An 
automated real-time simulation of the fire situation was needed to 
replace the outdated manual training methods currently being used. In 
order to be successful, this simulator had to provide realism, be user 
friendly, be affordable, and support multiple scenarios. The EMCAT 
system meets these requirements and therefore represents an innovative 
training tool, not only for the fire fighting community, but also for 
the needs of other disciplines. 

1 . 2 Scope 

This document presents the final report for the EMCAT system 
developed by Essex Corporation. Three areas are covered: operational 

considerations, software, and hardware. The intent of this document is 
to provide final development information about the EMCAT system to NASA 
and FEMA. 
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2 . 0 IMPLEMENTATION 


This section provides information about the requirements and design 
concepts used in developing EMCAT, including trade-offs made during the 
process. Three areas are addressed: hardware, software, and video 

scenes . 

2 . 1 Hardware 


This section discusses the EMCAT hardware requirements and hardware 
design. The EMCAT hardware consists of the components required for the 
task, including the computer and the video disk player, the interfaces 
required between the components such as the video disk control card, the 
computer support hardware such as the disk drives and printer, and the 
operator interfaces such as the keyboard and monitors. 

2.1.1 Requirements 

The EMCAT hardware components must meet certain requirements. 

First, they must provide the capabilities required to perform the 
functions defined below. They must also be affordable and easy to 
transport, set up, and operate. The more detailed requirements for the 
system are listed below. 

1. The functions that the hardware must perform are: 

a. Operate software 

b. Output video images 

c. Allow for operator interaction 

d. Allow for software control of video images 

e. Provide status information to the operator 

f. Allow for easy scenario swapping. 

2. The hardware system must be affordable to many smaller 
training groups. This can be accomplished by using simple, 
commercially available ("off-the-shelf") components. A 
modular approach using readily available components and 
standard interfaces helps keep the system price down for users 
that already own some components. 

3. An integrated package is required to provide ease of handling 
and transporting, compactness, and ease of set-up. Since 
component level maintenance is desired for simplicity, the 
various components in the system must be integrated intact. 

All components must be removable by non-skilled personnel for 
maintenance. The system console must conform to human 
engineering design standards and must be attractive. 

4. A highly desirable feature to make the system much more 
versatile to the users is the ability to use the individual 
components for their original purpose. This would allow other 
software to be used on the computer and other video disks to 
be used on the player. 
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2.1.2 Component Selection 

The components which are required, along with the selection 
criteria for each, are listed below. 

1. The computer selected to control the EMCAT system is the Apple 
lie computer. In terms of capabilities required, availability 
of higher level languages and operating systems, availability 
of interface hardware, and price, the Apple was superior to 
other available computers. The Apple also has the advantage 
of having an extensive line of software available, thus 
providing the user with a computer for tasks other than EMCAT. 

2. The video disk player selected to generate the video scenes is 
the Pioneer LD-V6000 advanced Laserdisc. This player is an 
industrial quality machine capable of very fast scene 
switching and communication with a computer through a standard 
serial interface (RS-232C) . 

3. The other components include a text monitor, two disk drives, 
a printer and interface, a clock, and a video disk interface. 
These were selected from those available as meeting the 
requirements at the lowest cost and are listed below. 

a. Text Monitor - Sanyo 12 in. Monochrome Monitor 

b. Disk Drives - Apple Disk II or MicroSci A2 5i in. floppy 
drives with Apple control card 

c. Epson RX-80 printer and Dumpling buffered interface 

d. Clock Card - Timemaster II H.O. from Applied Engineering 

e. Video Disk Interface - Apple SuperSerlal Card. 

2.1.3 Enclosure Design 

The EMCAT enclosure must house the hardware components in a manner 
that places them in the correct operating orientation as well as makes 
them accessible for repairs. These factors were considered in designing 
the enclosure shown in Figure 1. The cabinet closes into a solid box 
for transport and has been provided with casters and handles. When 
opened, the cabinet provides an ergonomically correct workstation for 
the system operator and easy access to the components. 


Notice : Apple lie is a trademark of the Apple Computer Company, 

Cupertino, California. Laserdisc is a trademark of the Pioneer Video, 
Inc., Montvale, New Jersey. 
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2.2 Software 


The EMCAT software provides the brain of the system. Without it no 
simulation would exist, only a set of video images without any control. 
This section discusses the requirements for the software and provides a 
review of the methods of implementation. 

2.2.1 Requirements 

At a top level, the EMCAT software is required to support the 
following functions: 

1. Accept Operator Inputs 

2. Resource Allocation and Tracking - including personnel, 
equipment, water, and time 

3. Structure /Situation Tracking - including fire and smoke 
progression, fire and water damage, victim condition, and task 
progress 

A. Video Scene Control - including determining the proper video 
scene to reflect the current situation and controlling the 
video disk player through the interface card. 

5. Update Operator Status - including the status display on the 
text monitor and printed reports both during and after the 
simulation. 

The software must provide these functions in a real-time mode and must 
provide these functions for multiple fire ground scenarios. Flexibility 
shall be provided to customize a scenario to individual user's needs, 
realizing that such customizing is limited by the video disk. 

In addition to the functional requirements listed above, the 
software must conform to certain programming standards. These include 
the use of structured programming and code modularity. The use of a 
compiled language, such as PASCAL, is also required to provide the 
processing speeds needed to keep up with all of the functions in a 
real-time mode. 

2.2.2 Implementation 

To meet the requirements on the software discussed above, the Apple 
Pascal system, version 1.2, was selected for developing the EMCAT 
software. The system not only provides the PASCAL compiler, but also 
provides an editor and the necessary file management utilities to 
support the software development. The PASCAL language is designed for 
structured programming techniques which simplifies code debugging and 
maintenance . 

The EMCAT simulation software was generated in three sections to 
better utilize the available memory resources of the Apple computer. An 
introductory section provides operating instructions, scenario pre-plan 
information, and several other options for an instructor/operator . The 
main section is automatically invoked by the introductory section. The 
main section performs the functions required to support the simulation 
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session. The reporting section is automatically invoked by the main 
section upon termination of the simulation. The reporting section 
provides final status information to evaluate the trainee’s performance 
in the simulation. 

2.2.2. 1 Database 

The software was designed to allow for multiple scenarios by using 
a database to provide most of the information to define the scenario. 

An editor has been developed to allow the user to modify the databases. 
This provides the benefit of allowing database changes prior to any 
simulation session, thus providing the capability for users to custom 
tailor the scenarios to their needs. At the start of a simulation 
session, the software reads in the database information. 

One section of the database defines the units and areas in a 
session, including the burn and put-out characteristics, the search 
order and time, and the location of victims. This information defines 
the scenario's structure and default progression. 

Another section of the database defines the resources available for 
the scenario. Up to 10 companies can be included, with the arrival 
time, number of firefighters, amount of water, and various fail flags 
for each company defined. The services available and the number of 
hydrants available are also defined. 

The final section of the database defines the tasks which can be 
performed by the operator. These include search and rescue, laying a 
line, putting water on an area, trenching, ventilating, and operating 
the machinery. The information provided for each task includes the 
number of firefighters required, the various times required, whether a 
task is cancelable and, if so, the time required to make the resources 
available for reassignment. The effects of some tasks, such as search 
and rescue, are built into the software. The effects of other tasks, 
such as putting water on the fire, are defined by the rules. 

For more information about the contents of the database, see 
Section 5 of the EMCAT System Operations Manual. 

2. 2. 2. 2 Physical Simulation 

The EMCAT software is designed to provide a simplified simulation 
of the real physical properties and behavior of the fire in the 
structure. This approach was taken to allow the software to more 
closely simulate the effects of time and operator inputs on the fire. 
Most of the inputs for this software are provided by the area definition 
portion of the database. 

The default fire progression is defined by a series of ignite times 
in the database and by a series of coefficients which can be set by the 
rules. The ignite time indicates the elapsed time into the simulation 
at which each area will ignite. In a default progression, 
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each area will ignite in a predetermined sequence. The coefficient 
provides for an adjustment to the ignite time in response to certain 
actions by an operator. It can be positive which causes the ignite time 
to be accelerated, or negative which causes the ignite time to be 
delayed. For example, water in one area may cause an adjacent area's 
slow coefficient to be set to delay or completely halt the fire spread. 
Venting an area may cause that area's coefficient to be set to 
accelerate the spread of fire into that area. 

Once an area is on fire, the simulation uses the following equation 
to determine the amount of fire involvement in that area: 

%FIRE = %FIRE + (CFIRE) - (CWATER * WATER 1 ’ 2 ) 

In this equation, the WATER term is the amount of water (in gallons per 
minute) being put in the area. The CFIRE coefficient, which is defined 
in the database, determines how fast the fire in the area will build 
(CFIRE is in percent growth per second). The CWATER coefficient, which 
is also defined in the database, determines how fast the fire in the 
area will be extinguished (CWATER is in percent extinguishment per GPM 
per second) . 

The fire growth equation is invoked every 4 seconds for each area 
on fire. The amount of water being put into an area is automatically 
factored in. If the water Is increased, the effectiveness of it 
increases exponentially as in an actual fire. Insufficient water into 
an area can cause the fire growth to slow down, but not stop. 

2 . 2 . 2 . 3 Tasks 

The operator's inputs to the EMCAT simulation are defined by the 
tasks which the available firefighters can perform. As tasks are 
performed, they affect the default fire progression, the disposition of 
victims, or the resources of the scenario. The manner In which a task 
affects the scenario is defined in the software for some tasks or in the 
rules for the other tasks. 

There are a limited number of possible tasks in the EMCAT 
simulation: laying a line to a hydrant, putting water on an area, 

ventilating an area, trenching an area, search and rescue, and 
communications. The resource and time requirements for these tasks are 
defined in the database for each scenario, as discussed in the previous 
section. For each task, the operator must provide certain parameters to 
the software such as the line size to use, the area being affected, and 
the number of firefighters to perform the task. 

Note that if the operator selects a company with insufficient idle 
firefighters assigned to a task, the software will allow the operator to 
reassign those firefighters. If a firefighter is reassigned, the 
effects of the task he /she was previously involved in are negated and 
the firefighter will begin performing the new task after a "backout" 
period of time. 
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2. 2. 2.4 Rules 


In order to define the effects of actions of the operator on the 
fire status, a set of rules is developed for each scenario. Rules are 
incorporated into the software as a series of conditional (IF) 
statements. A rule can have conditions such as time, water status, and 
ventilation status. If a rule's conditions are true, the rule can 
change the amount of water, the "slow coefficient," or the water or fire 
coefficients of various areas. Rules are also used to end a simulation 
based on the current video scene and to switch from one scene to the 
next . 


2.3 Video Scenes 


The most challenging aspect of developing the EMCAT system was the 
development of a low cost method of generating the realistic and dynamic 
visual fire scenes. This section lists the scene requirements and 
describes the method used for generating the images. 

2.3.1 Requirements 

The contractual requirements for the visual scenes are: 

1. Visual sequences shall be limited to an affordable number 
while providing sufficient variety for meaningful scenarios. 

2. The images of burning structures shall be as realistic as 
possible. Flame shall grow or diminish in a natural way. 

Smoke shall change from dark to light (steam) at the 
appropriate time. 

3. Stylistic representations of fire and smoke are unacceptable. 

4. Simulation depth and realism shall be achieved in such a way 
that production doesn't become prohibitively expensive, for it 
is anticipated that users will demand many affordable, perhaps 
even customized, scenarios. 

2.3.2 Implementation 

In order to meet the requirements for the visual scenes at an 
affordable price, several concepts were considered. These are listed 
below along with the advantages and drawbacks of each: 

1. The use of a Chromakey system to electronically superimpose 
fire and smoke on an image of the structure was considered. 

This method allows the "stock" fire and smoke footage to be 
electronically scaled and positioned over the structure. A 
photograph of the structure would be sufficient for this 
method . 
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There are three disadvantages to the Chromakey method. The 
first is the "halo" effect which is evident on the overlayed 
objects which gives the objects a "pasted on" look. The 
second, and most serious, disadvantage is the prohibitive cost 
of renting the required electronic editing equipment. The 
third disadvantage is the scene degradation resulting from the 
editing the dynamic elements onto the scene one at a time. 

2. The use of real scale models of the structure with real fire 
and smoke was considered. This method permits the realistic 
geometry of the structure and the capability to incorporate 
structural damage. 

The main disadvantage to this concept is again one of cost. A 
model of the larger and more complex structures could cost 
several thousand dollars. Another disadvantage is the problem 
of scaling the fire and smoke effectively. 

3. The generation of the images using only software graphics and 
animation was considered. This concept would provide for very 
flexible scene generation since little or no real imaging is 
required. If carried to an extreme, this system would even 
allow for the elimination of the video disk, with the software 
electronically generating flame and smoke on an image. 

Again, the major disadvantage of this concept is cost. Systems 
capable of generating the required scenes are very expensive 
and the process is labor intensive, at least initially. 

Current systems also lack the ability to generate completely 
realistic images and animate them convincingly. Current 
scenes tend to look cartoonish. 

4. The method considered and ultimately developed for generating 
the EMCAT visual scenes is the optical overlay concept shown in 
Figure 2. In this concept a photograph of the structure is cut 
to allow smoke to pass through the windows, door, vents, etc. 
Two black templates with the shape of the structure are made. 
Behind one template fire is generated in the windows, doors, 
vents, etc. White smoke (steam) is pumped through the windows, 
doors, vents, etc, of the other template. The three images 
are optically overlayed by using a half-silvered mirror. 

This method offers the advantage of being inexpensive, since 
little specialized equipment is required. It also provides for 
realistic geometry of flames and reasonably realistic flame and 
smoke . 

The disadvantages of this method mainly stem from the problems 
of scaling flame and smoke down to the required size. Both 
fire and smoke tend to move too quickly at this scale and the 
fire tends to be unrealistic and difficult to control. The 
speed problem was resolved by slowing down the image to 
one-half the original speed. The fire problem was resolved by 
using simulated flames created by fast-moving segments of 
cellophane . 
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3.0 METHODOLOGY OF SCENARIO DEVELOPMENT 


This section describes the steps used in developing each scenario 
for the EMCAT system. This development methodology was a key design 
goal of the EMCAT development contract. The development process assumes 
that a technical consultant for fire progression and fire fighting is 
involved to provide all the required information. 

3.1 Incident Definition 


The first, step in the development of a scenario is the selection of 
the training objective, i.e., fire situation to be simulated. Once this 
is known, the following information must be generated. 

1. A structure is selected and photographed from the appropriate 
vantage point. Other photographs showing exposures, other 
sides of the structure, or other pertinent views can also be 
taken for inclusion in the pre-fire section of the video disk. 

2. The structure layout and construction is determined. As long 
as the external features are not violated, the real floor plan 
can be altered to fit the fire progression desired. 

3. The fire progression is determined by selecting a point of 
origin and determining the fire flow paths. Technical input 
is required to determine fire growth rates, the time to burn 
through an obstacle, etc. For each area in the structure, the 
fire start time, burn rate, and extinguishment rate need to be 
determined. 

4. An initial assessment is made of the occupancy rate and the 
location of the victims, as well as the resource availability. 
This information is in the database and can be updated later as 
desired. 

3. 2 Responses and Effects Determination 

Once the basic incident has been determined, the possible fire 
fighting and rescue responses can be determined. The effect on the fire 
progression for each response is also determined. Note that each 
response needs to be assessed individually. The following types of 
responses need to be considered. 

1. Application of water for each area or groups of areas. How 
will it affect the fire in that area and how will it affect the 
fire progression into other areas? 

2. Ventilation of an area. If done in the correct place, this 
could greatly slow the fire spread. If done incorrectly, it 
could greatly increase the fire spread. 
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3. Search paths for each group of areas need to be determined. 

4. Any areas which can only be reached through another area need 
to be determined. The simulator will allow the scenario to be 
defined with these "paths" which must be extinguished before 
another area can be reached. 

3.3 Scene Story Board Development 

Using the fire progression and responses developed above, the scenes 
for the scenario can be determined. These are drawn on simple outline 
drawings of the structure to create a story board which is used during 
filming. The location of fire, smoke, and steam is shown for each scene 
in the story board. The process of development is as follows: 

1. The fire progression assuming no action, or "default" 
progression, is drawn. This is normally between 5 and 10 
scenes long. Each time a major change in the smoke, fire, or 
steam occurs, a new scene is required. The progression should 
end when all major areas are involved. 

2. For each scene in the default progression, determine the visual 
effect, if any, for each possible response. Water application 
on each area which shows smoke or flames will require a new 
scene. Ventilation of an area will require a new scene (by 
showing fire appearing through the vent). Fire appearing due 
to alternate progressions or due to the removal of water will 
require a new scene. As new scenes are developed, these are 
also drawn on the story board if they do not already exist. 

3. The process in step 2 is repeated for each scene developed 
until an "end" scene is reached. An end scene will usually 
show all areas extinguished, major areas protected while others 
are extinguished, or major areas burning out of control while 
other areas are protected or extinguished. 

4. When all scenes have been illustrated on a story board, the 
number of scenes may be excessive. Since only about 100 scenes 
will fit on a video disk (assuming 15 second scenes and 
overhead for pre-plan information, etc.), the scenes may need 
to be reduced. 

Some factors which will help in reducing the number of scenes are: 

a. Eliminating transition scenes. For instance, fire will 
immediately turn to steam in the simulation. 

b. Combining similar scenes, especially those which are the 
result of second or third generation responses. 

c. Limiting the extent of the incident simulated. Once an 
attack has been established and depicted, the simulation 
should end. 
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5. 


Once the story board is completed, the scenes can be filmed and 
edited. Each scene should be filmed at least 10 seconds longer 
than required to allow for editing and video disk overhead. 
Since the order of the scenes on the video disk is not 
important, it should be selected for ease of filming and 
editing. 

3.4 Database and Software Programming 

In this phase of scenario development the information generated 
during the previous phases is used to develop the scenario specific 
software and the database. The database is developed from the structure 
definition, fire progression and resource availability information 
defined in the Incident Definition phase. The scene change rules in the 
database can be directly transferred from the information developed for 
the scene story boards. The rules and any other special software 
required for the scenario can be determined from the information 
determined in the Responses and Effects phase. This includes areas 
where firefighter actions can be taken, any limitations on 
accessibility, and the effect of ventilation and water application in 
the various areas. 

4.0 ASSUMPTIONS 

This section documents the assumptions which are built into the 
software, as well as those made during development of the software. A 
list of those assumptions follows. 

1. During search and rescue operations: 

a. If area is greater than 50% involved, it will not be 
searched and will result in a "Too Hot to Search" message. 

b. One firefighter is required to rescue each victim found. 

c. If the number of firefighters searching is less than the 
number of victims found, excess victims will be left 
unrescued. 

d. If the number of firefighters searching is greater than 
the number of victims found by more than one (i.e., 2 or 
more firefighters), then the victims will be rescued and 
the search will continue with the remaining firefighters. 

e. Firefighters will not re-enter the structure after 
rescuing operations unless commanded. 

2. During water application: 

a. Any time water is being used from an engine, a pump 
operator will be assigned automatically by the software. 

b. The turret is assumed to be pre-connected. 
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c. The water application rates for the various line sizes 
are : 


3/4" 

Line 

= 

15 

GPM 

1" 

Line 

= 

30 

GPM 

1-1/2" 

Line 

= 

80 

GPM 

1-3/4" 

Line 

= 

200 

GPM 

2-1/2" 

Line 

= 

250 

GPM 

Turret 

Line 

= 

500 

GPM. 


These figures were provided by Mr. Blair of the National 
Fire Academy. 

d. If firefighters are assigned to put water on an area which 
is not on fire, no water will be applied (no water damage) 
but the effects of water will be applied. 

e. While applying water, firefighters will search the areas 
and, if victims are found, will abandon their hoses to 
perform rescue. 

f. If the water. supply runs out ("TANK EMPTY"), any 
firefighters applying water will automatically back out 
and will have to be reassigned when the water supply is 
restored. 

3. Regarding the water supply: 

a. The water in the tanks of all the engines or tankers on 
the scene is assumed to be available to all firefighters. 

b. As soon as one engine is hooked to a hydrant, all engines 
are assumed to have access to an unlimited supply. 

c. A hydrant is assumed to be able to supply as much water as 
needed unless it is failed. 

d. When firefighters lay to a failed hydrant, they will 
report it and stop. They must be assigned to lay another 
line to an unfailed hydrant. 

4. For ventilation and trenching: 

a. If the area to be vented or trenched is above the third 
floor, an aerial ladder can be used to speed up the 
process, if available. 

b. If a saw fails, the firefighters will automatically return 
to get another saw. 
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5.0 SYSTEM REVIEWS AND RECOMMENDATIONS 


This section presents the results of the various demonstrations and 
reviews of the system. In the original contract, an evaluation period 
was provided whereby the system would be made available to various 
agencies for review. This was not performed as specified due to time 
and money constraints. However, an extended evaluation of the system 
has been conducted on the system by the National Fire Academy, since 
they have had access to an EMCAT system for almost 11 months due to an 
early delivery. A system has also been purchased by the Kentucky 
Vocational Education system and has undergone extensive evaluation over 
an 8 month period. These extended evaluations have allowed many of the 
problems found to be corrected in later versions of the software, a 
capability which would not have been possible under the original 
contract. 

5.1 Reviews 


Listed below are the demonstrations and reviews of the EMCAT system 
which have been conducted during the contract period. Note that those 
demonstrations which were held using the prototype EMCAT system 
developed by NASA are not listed. 

1. National Fire Academy - Two review/discussion visits to the 
NFA January 15-16, 1985 and December 9-10, 1985. Two 
review/discussion visits by Mr. Blair to Essex on February 
14-15, 1985 and July 15-16, 1985. During these visits 
requirements for scenarios and software and problems with 
the system were discussed. Most of these requirements 
have been implemented and most of the problems have been 
solved in the final EMCAT system. 

2. Kentucky - The Public Safety Occupations division of the 
Kentucky State Vocational Education system has purchased a 
system for the purpose of evaluation. On August 22, 1985 
several demonstrations of the EMCAT system were arranged for 
Essex personnel to attend and gather comments. The system was 
also used during the Lake Cumberland Regional Fire School held 
on August 24-25. The details of these reviews and the results 
are provided in Appendix A. 

3. The system was demonstrated as part of the National Fire 
Academy presence at the Fire Department Instructors Conference 
held in Cincinnati during March 20-21, 1985. 

4. The system was demonstrated at the U. S. Navy's Southeast 
Regional Fire Officer's Training Course at Whiting Field in 
Milton, Florida during December 3-5, 1985. 

Although most of the problems or discrepancies which were uncovered 
during the various reviews have been incorporated into the final version 
of EMCAT, some of the comments were not within the scope of the 
development effort. 
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5.2 Recommendations 


Several recommendations have been made for the EMCAT system which 
would greatly enhance the EMCAT but were not within the scope of the 
original contract. These are listed below. 

1. Make the EMCAT system available for IBM and IBM compatible 
equipment. It was also mentioned during the Navy review that 
the U. S. Navy and Air Force have selected the Zenith Z-151 
personal computer, which is IBM compatible. 

2. An input mode easier to operate than the current keyboard had 
been requested many times. The touchscreen software, which 
will greatly simplify user inputs, has been developed as part 
of the development effort. If found to operate as expected 
during subsequent testing, this version of the system will 
probably be the version which is marketed by Essex. 

3. Multiple fire situations for a scenario were requested in order 
to increase the factors available to training officers. The 
database makes this capability currently available in software, 
the only limit being the scenes available on the video disk. 
This could be made possible by generating more fire 
progressions on one video disk (limited to 2 or 3 fire 
progressions) or on multiple video disks (unlimited fire 
progressions) . 

4. Various suggestions have been made for providing a "difficulty 
factor" in the software which could be set by the instructor 
prior to each simulation session. This factor could be 
incorporated by simply increasing the speed of the fire spread 
or could involve adjusting many or all aspects of the 
simulation. 

5. Many reviewers have complained about the inability to see any 
of the hardware or personnel fighting the fire. Suggestions 
include showing trucks as they arrive, showing personnel going 
into the structure when assigned, and showing lines that are 
put into a building. These could be accomplished with digital 
graphics overlayed over the video image. 

6. The addition of sound effects has been mentioned as a 
worthwhile enhancement to the realism of the simulation. These 
include both background sounds of the fire scene and voices to 
simulate radio transmissions. The current system will not 
support sound because the video disk player shuts off the sound 
during slow-speed play modes, which are used for all EMCAT 
scenes. Newer technology players, or external sound sources 
such as synthesizers, would provide the capability for future 
development . 

7. Many requests have been made by potential users in other fields 
for similar systems. Applications which have been considered 
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include police and security force training, plant operations 
training, driver training, and command post operations training 
and management. Essex is considering the development of other 
systems and is seeking funding for this purpose. 

8. In order to eliminate the limiting aspects of the video disk in 
terms of the number of scenes and the unvariability of the 
simulation, it is becoming- apparent that the newly emerging 
computer graphics technology will provide some exciting 
breakthroughs. Using software very similar to that already 
used in the EMCAT system, a simulator using this technology 
could generate an unlimited number of fire progressions for a 
given structure. The small amount of realism lost would be 
offset by an increase in fidelity of transition scenes, 
variability of smoke and flame density, and even structural 
damage due to fire. 

In summary, the EMCAT system has been demonstrated to be an 
effective device for training fire scene commanders in the allocation 
and deployment of resources and real-time decision making. The system 
also appears to be marketable in the fire fighting training community, 
and Essex plans to pursue additional development and sales activities. 
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APPENDIX A 

EMCAT DEMONSTRATIONS AND REVIEW COMMENTS 
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A listing of the demonstrations and reviews conducted in Kentucky 
during August 22-25, 1985 and a listing of the comments and problems 
recorded during those reviews follow. Note that the "new version" of 
the software referred to in the text is the final version delivered at 
the end of the EMCAT contract. 

A. Demonstrations and reviews of the EMCAT System: 

1. Campbellsville-Taylor County Fire Department; August 22. 

2. Elizabethtown Fire Department; August 22. 

3. Cave City Fire Department; August 22. 

4. Lake Cumberland Regional Fire School; August 25. 

B. Comments and problems recorded during the reviews listed above: 

1. Develop an EMCAT System on the IBM Personal Computer. 

2. Provide an audio track of fireground sounds during the 
simulation. 

3. Output status messages, which currently appear on the status 
screen, via an audio system. 

4. Provide a status monitor, currently provided only for the 
operator, for the trainees. This is possible with the current 
system by "splitting" the video signal for this display. 

5. Show equipment and personnel on the video scene to help in 
tracking resources. Other alternatives to this concept include 
providing a plot plan of the fire scene with some means of 
tracking available resources. This can either be a digital, 
computer-controlled scene; a table-top, three dimensional 
model; or a magnetic, manually controlled "simulation board" 

(as currently used with the sand-box systems). 

6. Provide standard pre-fire plan information in the scenario 
manual. Also provide information about the time of day, 
weather, and other factors which affect the incident. These 
provided in the scenario manuals. 

7. Develop a Tanker/Chemical Spill/Hazardous Materials scenario. 

8. Several comments were received which would make EMCAT more 
useful for volunteer departments: 

a. Randomize the number of firefighters available for each 
scenario . 

b. Stagger the arrival of firefighters at the scene. This is 
supported by the new version being developed. 



c. Provide for drop tanks, ponds, or other water sources. 

Some of these sources, such as ponds, can be supported in 
the current system by using hydrants. 

d. Provide the capability of calling for additional companies 
rather than calling for the next alarm. 

e. Provide the capability to assign any firefighter to any 
task, regardless of which company to which they belong. 

9. Several comments were received about the printout provided by 
the system: 

a. Print the line size used when water is applied. This is 
supported by the new software version. 

b. Print the total amount of water used during the simulation 
session. 

c. A problem exists with the determination of water damage 
which will be corrected in the new software version. 

10. The effect of smoke inhalation on victims is not supported. 
However, the new version of the software automatically injure 
the victim when the fire starts in the area and kills the 
victim when the fire reaches about 50% involvement in the area. 

11. Provide a flag by which the use of breathing apparatus must be 
requested or the firefighter will be injured. Currently, the 
operator can disable a firefighter manually. 

12. Support the ability of firefighters to search a room with a 
line. This is supported by the new version of the software. 

It was also noted that replacements for a water crew that had 
abandoned their lines to perform a rescue would have a 
decreased setup time. 

13. It was pointed out that one firefighter was usually assigned to 
protection with a charged line when ventilation was being 
performed. This can be supported in the current system by 
setting the minimum number of firefighters required to perform 
the ventilation task. 

14. Provide some method to injure or kill firefighters if utility 
support is not requested or if the power and gas lines are not 
disconnected. 

15. Currently, if a firefighter is sent to an area with a line, 
water will be applied even if the area is not on fire. This 
is changed in the new version of the software. 
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16. The question of the EMCAT system use in the one-on-one 

training mode versus the classroom mode (with an instructor 
and/or operator) arose. The current system requires some 
prior operator knowledge. However, it has been designed for 
both modes of training. A touch screen was subsequently 
implemented to make the system easier to operate. A light pen 
input system could also be implemented. 
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